The original approach that the X Window System took to sharing the graphics hardware is to allow only a single program, namely the X server, to directly manipulate the graphics hardware. X clients send rendering requests to the X server to dispatch. Effectively, the X server process acts as a rendering proxy for all X clients. For accelerated OpenGL graphics hardware, this approach has two problems.
First, OpenGL maintains a large amount of rendering state that is maintained in hardware for GTX-RD systems and even more so for GT-XRD systems. For typical 2D X operations, each rendering operation downloads its necessary hardware state since this setup overhead is small. For OpenGL, the state is potentially quite large when all the lighting parameters, matrices, modes, and texture memory is considered. For GTX-RD systems and particularly for GT-XRD systems for OpenGL to be feasible within a window system, there must be a way to efficiently context switch the graphics hardware.
Second, when accelerated graphics hardware is sufficiently fast, the overhead of generating, sending, and dispatching X protocol requests compared to the hardware's rendering speed is high. A fast graphics subsystem cannot meet its performance potential if it cannot be delivered OpenGL commands fast enough. To remedy this situation, OpenGL's GLX extension that integrates X with OpenGL provides OpenGL implementations the option of supporting direct rendering so that local OpenGL programs can render directly to the graphics hardware.
When the X server does all rendering to the hardware, the X server context switches the hardware as necessary. But when direct rendering is supported, graphics context switching has to be managed among unrelated processes in separate address spaces. If the graphics hardware supports context switching asynchronous to rendering, the kernel and window system can ``conspire'' to virtualize graphics for OpenGL programs without those programs knowing [7].
Another approach to speeding context switching is to support multiple contexts within the graphics hardware. This can be expensive because OpenGL contexts can be large and supporting multiple contexts in hardware requires hardware resources. Devoting hardware resources can be hard to justify since multiple contexts do not speed up the performance case of a single renderer. Even with multiple hardware contexts, the system may still run out of hardware contexts, so context switching OpenGL state to and from host memory must still be supported.
Figure 7: Clip rectangles define the clips for the two windows with
simple drawable regions. One clip rectangle is needed for the rectangular
window; two clip rectangles are needed for the L-shaped window. Three
clip IDs are assigned to the three windows with irregular clips.
Notice that clip ID zero is used as a ``slop'' clip ID for the screen
region not assigned to the clip ID windows (which includes the windows
clipped using clip rectangles).